add flag to include payload in produceBlockV4#2
add flag to include payload in produceBlockV4#2shane-moore wants to merge 2 commits intoepbs-standardizedfrom
Conversation
shane-moore
force-pushed
the
produce-block-v4-with-payload
branch
from
52cf903 to
2013831
Compare
| payload later. This endpoint is specific to the post-Gloas forks and is not backwards compatible | ||
| with previous forks. | ||
|
|
||
| When self-building (local execution payload), the response will include the full block contents |
There was a problem hiding this comment.
in ethereum#519 the conclusion was to leave it up to clients to support blinding the response, eg. in Lodestar we have a flag --blindedLocal and corresponding query param to tell the bn to not return full block contents but rather cache them which makes the block production stateful but there is no drawback in a 1:1 setup
I think it would be good to standardize this kind of query parameter in produceBlockV4 and leave it up to clients whether the wanna implement it or not, ie. if a client doesn't wanna implement it they can always set the query param to false
nflaig
left a comment
nflaig
left a comment
There was a problem hiding this comment.
something to consider, if we return both the beacon block and execution payload here, do we also want an api to publish both, or are we fine with having 2 separate publish apis
|
Speaking on behalf of Vouch, we find this approach preferable to maintain the statelessness of the REST API and allowing us to leverage multiple clients in block production.
This would be ideal for the stateless flow. |
does it matter for that to have a single publish api call or 2 separate ones? but I can see that it's simpler for beacon node to process the data since you need to process the beacon block before you can process the execution payload to which the beacon block committed |
Is the submission process stateful, I.e. do you have to submit the payload to the same BN that you submit the beacon block to? If it's stateful then a single submission endpoint for both would make sense to keep the API stateless, but if it's not stateful it might be more consistent (for MEV and local production) to keep them separate. For my benefit - is the worry that, if you submit the block to one BN and then the execution payload to a second BN, that the second client might not have seen the block yet? |
the BN needs the beacon block first to validate and process the execution payload however it's not required to submit both via the api there will be a queue mechanism in clients for gossip as you can't be sure that you receive the beacon block before the execution payload there so for api, it could be similar, BN shouldn't care if it receives the beacon block/payload via gossip or api
this is kinda what I wanna avoid, it's a implementation detail but I think we might be fine with keeping the 2 apis separate, and not have a specific publish api for local blocks |
I'd just keep the 2 separate publish endpoints, that seems cleaner to me, they are two different objects being submitted. That way we can also push out the |
4 participants
Resolves comment in the epbs standardized PR by adding a flag to
produceBlockV4to respond with the payload envelope, blobs, and kzg_commitments alongside the CL block in the self-building case as to continue supporting multi beacon node setups